-
Notifications
You must be signed in to change notification settings - Fork 527
Use dependency injection for runner #10326
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/10326
Note: Links to docs will display an error until the docs builds have been completed. ❌ 14 New FailuresAs of commit c4bf4be with merge base b71f03c ( NEW FAILURES - The following jobs have failed:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
This pull request was exported from Phabricator. Differential Revision: D73165546 |
This PR needs a
|
Summary: X-link: pytorch/executorch#10326 Pass in runner components, move most of the instantiation logic from `load()` to a new static API `create()`. This adds testability to runner components. Differential Revision: D73165546
Summary: X-link: pytorch-labs/tokenizers#53 Pass in runner components, move most of the instantiation logic from `load()` to a new static API `create()`. This adds testability to runner components. Differential Revision: D73165546
1fe0afa
to
16e3256
Compare
This pull request was exported from Phabricator. Differential Revision: D73165546 |
@@ -30,18 +30,22 @@ namespace example { | |||
|
|||
class ET_EXPERIMENTAL Runner : public executorch::extension::llm::IRunner { | |||
public: | |||
explicit Runner( | |||
// Static factory method to create a Runner instance | |||
static std::unique_ptr<Runner> create( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will most users interact with runner via this API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am generally opposed to both tests that use mocks and dependency injection.
I am generally opposed to mocks because they tend to produce change detector tests. For the case at hand, why not create a Runner and see if it decodes the right number of tokens?
I am generally opposed to dependency injection because pass-from-above is typically all you need in order to accomplish the usual stated goals. In this particular diff, I don't immediately understand what Runner::create is accomplishing; I don't see any sort of flag that causes it to return a different Runner in a test environment, nor do the tests use it.
} // namespace | ||
|
||
Runner::Runner( | ||
std::unique_ptr<Runner> Runner::create( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specifically, it looks like create() could just be another Runner constructor; it's not clear to me why it has to be a static method instead.
|
||
[[deprecated( | ||
"This constructor is deprecated. Use the constructor without temperature parameter instead.")]] | ||
// Constructor with dependency injection | ||
explicit Runner( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like I was confused in my original comment. This form of dependency injection (pass from above) is fine; I thought Runner::create
was going to be part of a trend of giving everything a create method and therefore building our own dependency injection framework.
Summary: Pull Request resolved: #10338 The ownership of these components need some clarification. * `Module` should be shared by `TextDecoderRunner` and potentially `TextPrefiller` (or `ImagePrefiller` in multimodal runner). * `TextDecoderRunner` should be shared by the `TextPrefiller` and `TextTokenGenerator`. * `Tokenizer` should be owned by the `Runner` as well as `TextTokenGenerator`. Differential Revision: D73399600 Reviewed By: kirklandsign
Summary: X-link: pytorch/executorch#10326 Pass in runner components, move most of the instantiation logic from `load()` to a new static API `create()`. This adds testability to runner components. Differential Revision: D73165546
Summary: X-link: pytorch-labs/tokenizers#53 Pass in runner components, move most of the instantiation logic from `load()` to a new static API `create()`. This adds testability to runner components. Differential Revision: D73165546
16e3256
to
91c0f0a
Compare
Summary: Pull Request resolved: #10326 X-link: pytorch-labs/tokenizers#53 Pass in runner components, move most of the instantiation logic from `load()` to a new static API `create()`. This adds testability to runner components. Differential Revision: D73165546
This pull request was exported from Phabricator. Differential Revision: D73165546 |
91c0f0a
to
c4bf4be
Compare
Summary: X-link: pytorch/executorch#10326 Pull Request resolved: #53 Pass in runner components, move most of the instantiation logic from `load()` to a new static API `create()`. This adds testability to runner components. Differential Revision: D73165546
Summary:
Pass in runner components, move most of the instantiation logic from
load()
to a new static APIcreate()
.This adds testability to runner components.
Differential Revision: D73165546